Temporary elevation via Jamf Self Service’s Admin Minion (the “Admin for 30 min” action) repeatedly restored workflows that required local admin — for example software installs/updates, developer tools/Homebrew, privacy permissions (Teams/Zoom), macOS/security updates, and font installs for Adobe. When the Minion entry was missing or nonfunctional, support restored the Minion item in Jamf or assigned the user to the designated short‑term admin group (for example MAC‑LocalAdmin‑shortterm); group‑membership propagation typically took a few hours and a restart/relaunch of Self Service commonly made the entry appear. Jamf/MDM/catalog or policy-application failures sometimes prevented elevation; restoring the Admin Minion or applying server‑side Jamf fixes and allowing policies to reapply reinstated sudo/admin access — at least one incident required a specialist-team server‑side fix before policies took effect. Device‑enrollment conflicts in which Intune/Company Portal reported the Mac as registered with another MDM correlated with inability to install software or self‑elevate; resolving the enrollment/MDM conflict or restoring Jamf‑managed Self Service functionality addressed those cases. In observed cases, admin rights assigned via Intune Company Portal propagated to macOS devices in about 30 minutes when applicable. For sustained needs, long‑term admin access was provided by adding the user to the appropriate long‑term admin group, by changing Admin‑Access‑Time to extend Minion durations, or by enabling/assigning a long‑duration Self Service entitlement (documented as “request long time Admin rights”); one case produced a three‑year admin grant. Self Service sometimes required federated login (Microsoft/Okta or Apple) before Minion could run; locating Self Service via Launchpad or Finder was effective when the Minion entry was not immediately visible. Alternate flows (Get Software/software portal or the Jamf app) occasionally succeeded when Minion was missing. In one newly observed pattern after the Self Service → Self Service+ upgrade, the new “request now” administrator flow could report success but fail to actually grant local admin/sudo (sudo continued to report “user is not in the sudoers file”); those incidents were resolved by backend/server‑side agent fixes applied by IT. A few persistent cases were resolved by updating macOS to a later build, and one isolated case required hardware replacement.

Local administrator access was provided using established enterprise mechanisms and short‑term alternatives depending on policy and urgency. Routine installs were resolved by Company Portal/self‑service packages for common developer utilities (examples: Node.js, Java, Salesforce CLI) which avoided elevation in many cases. Time‑limited admin access was granted by adding users to the IUG‑AAD‑WindowsLAPS‑Users365Days AAD group or by issuing temporary local‑admin credentials/one‑time links delivered via SAFE App or email. Support recorded Azure AD/device synchronization delays of up to about one hour before LAPS credentials appeared; when LAPS/Intune showed no password, a greyed‑out field, or a LAPS password was refused by the device, incidents were escalated to specialists and interim access was provided via time‑limited AAD group membership or direct elevation when policy allowed. Short‑lived elevation emails/tokens occasionally expired and were reissued as needed. When UAC elevation failed with no clear error, one case was resolved by using the local account with machine‑qualified username and remote troubleshooting via TeamViewer confirmed access. Endpoint Privilege Management (EPM) failures were observed where the EPM client would not start despite Intune approvals and reported either missing elevated privileges or that the path could not be found; those failures were recorded and alternative access methods (time‑limited admin group membership or an administrator performing the action) were used where necessary, and at least one incident had no technical remediation logged. For file access and recovery, support located and copied autosave/recovery files to a usable location so users could open them (examples: recovering %AppData% Excel autorecovery files). For protected data that required local admin (for example E‑Lock exports), an administrator copied the data to removable media and tested it on another device before closing the ticket. For developer and data‑science toolchains requiring device‑level changes (WSL2 kernel updates, Docker daemon/network drivers, compilers, system‑wide PATH changes, enabling VT‑x in BIOS, etc.), support either granted time‑limited local admin, performed elevated installations remotely, or provided alternative developer resources (temporary VMs or reassigned hardware) when long‑term admin was inappropriate. BIOS virtualization changes sometimes required vendor assistance; vendor/device BIOS password state was documented during triage. Long‑term local admin remained restricted by policy; extended‑duration admin requests required formal manager/security approval. Unknown vendor/application administrator credentials and licensing concerns were escalated to vendors or specialists and recorded during triage.

Centrally deployed Intune/Azure AD endpoint/device‑control policies had disabled USB mass‑storage and MTP on managed Windows 11 devices, which prevented mounts and produced File Explorer errors like “Access denied” or “X:\ is not accessible.” Incidents were resolved by issuing centrally managed, time‑limited access exceptions (for example via Azure AD entitlement/access‑packages), applying group exclusions, or granting temporary administrator enables (commonly 48–72 hours); some requests required manager approval or Cyber Security escalation. Temporary grants typically propagated within a few hours but occasionally required a shutdown/restart or a manual policy sync (Settings → Accounts → Access work or school → select account → Info → Sync). Where direct USB use remained blocked, support moved data through approved channels (OneDrive, SharePoint, the SAFE app, Dropbox, IU research cloud) or assisted users to upload from a personal/non‑managed device so files would sync to the managed laptop. For some research workflows teams used an on‑prem Windows 10 device not subject to the Windows 11 USB restriction to copy media and then transfer via approved storage. DRM content (for example Adobe Digital Editions/Adobe ID or e‑readers) was handled by authorizing the content on a non‑company device and synchronizing it to the managed laptop or by granting a time‑limited exception. Some multimedia files (for example VOB video files) copied from blocked media still failed to open with default players; alternative players (for example VLC) were used where present. Microsoft Store app blocks were handled by obtaining apps through the Company Portal. Requests to grant access to an internal/local drive (for example adding a user to a local access group for a DevDrive) were treated separately and resolved by adjusting group membership via the specialist team rather than by changing the endpoint storage policy. Desktop support was not permitted to permanently override the central policy. For presentation/infoscreen use‑cases where USB access was inappropriate, the specialist team procured dedicated media players (for example Viewneo boxes) or other site hardware to feed content to displays instead of granting USB mass‑storage access. Presence of third‑party security software (for example Kaspersky at a high security level) did not alter enforcement of the central USB policy. In at least one case technicians explicitly denied USB access for photo transfer per policy and advised users to use a private computer to upload photos to cloud storage (examples included Dropbox or OneDrive).

Investigations repeatedly attributed content‑level access denials to identity or context mismatches, absent or incorrect owners, license/profile restrictions, group or dynamic‑group membership errors, automation execution identity, embed/authentication domain boundaries, corporate external‑sharing rules, or scheduled policy/automation removals. Representative findings and outcomes included: - Owner and ACL remediation: Historical Audit Committee files had been inaccessible after the owner left; access was restored by adding the requesters to the location ACLs or reassigning ownership. - Dynamic groups and Teams/SharePoint: Cases where expanding an Azure AD dynamic rule changed who could view channel content produced symptoms where users could read posts but not open the channel Files; investigations pointed to dynamic membership, SharePoint library scope differences for private channels and membership/propagation timing as the root causes. - Power Automate / flow execution context: Several incidents produced usable links only when the flow Owner executed them; troubleshooting identified execution identity/context as the cause and required escalation to the product/flow owner. - Recurring/automated revocations: Short‑term permission restorations were repeatedly undone by scheduled policies or automation; teams temporarily re‑granted access while policy automation was investigated and adjusted. - Teams private channels and meeting recordings: Files stored in private channel libraries or organizer OneDrive remained access‑controlled by separate libraries; restoring file‑level sharing or moving recordings to a channel library returned access in resolved cases. - Embedded/iframe content and LMS: 'Refused to connect' or inaccessible embedded content mapped to a separate authentication context or to allowed‑embed‑domain/permitted‑HTML policies in the consuming app; fixes adjusted allowed embed domains or addressed the service authentication boundary, with vendor escalation where vendor authentication prevented embedded access. - Third‑party form attachments: 'Page not found' outcomes were traced to vendor form/storage permissions; reporters were directed to the form owner or vendor permission contact. - Confluence, Miro and vendor tools: Missing edit/comment controls mapped to license/account types, absent space/board membership or legacy permission schemes; restoring membership, confirming license entitlements or fixing space permission mappings resolved access. - Jira / Issue Security: Visibility and edit blocks were traced to project scopes and Issue Security Levels; product administrators adjusted project configuration and security group membership where appropriate. - CARE / EPOS / document generation: Viewing and audit access required explicit CARE roles and proper location visibility; cross‑location visibility loss was resolved by restoring location assignments. DokGen/template problems were fixed by updating and redeploying templates/configurations. - Salesforce / CRM / Reports: Report failures and blocked folder operations correlated with profile, field or folder permissions; remedies involved restoring permission sets and field security so intended users retained access. - GitLab / internal apps / NTFS: Denials resolved after assigning correct project/group roles, updating in‑app rights or removing problematic NTFS/share ACLs, and handling checked‑out files or locks. - BIC / missing metadata: Files saved without author metadata became uneditable in repository roots; repository owners removed or repaired affected files to restore workspace integrity. - External sharing and anonymous reviewers: Requests to grant access to reviewers without verifiable external identity were evaluated against corporate external‑sharing policy and often treated as policy‑restricted; teams identified policy‑compliant alternatives. - Vendor support boundaries and permission portals: For vendor‑managed systems, support confirmed they only handled account provisioning and directed requesters to vendor permission portals or application/product owners when support could not change permissions. - Unresolved/escalated items: Some tickets (for example external consultant loss of PowerBI dashboard access and template access in the Learning Hub) were escalated to workspace/product administrators or specialist teams with no final resolution recorded in the ticket. General observations: resolutions commonly involved confirming license and account types, role/profile assignments, reassigning site/list/file owners, restoring explicit ACLs or group membership, and accounting for Azure AD/Entra propagation delays and client cache/stale sessions; investigators routinely advised reauthentication when user or execution context had changed and preserved privacy when reviewing file metadata or audit history.

Investigations identified two principal failure modes and several user‑facing symptoms. Records that pointed approver fields to external addresses were corrected to point to internal IU contacts, and the approval/account automation was changed to disallow self‑approval and require an internal approver so external workers could not approve or extend their own access. Lookup failures that routed cost‑center approvals to incorrect people were traced to use of the wrong Workday feed field (Cost Center Approver vs Cost Center Manager) and to email/ID mismatches in AtlassianUser/employee imports; source mappings and employee import records were reconciled so the approval lookup used the correct Workday field and matched approvers to AtlassianUser/employee records, after which the approval automation reliably located internal approvers. One admin‑permission request had timed out and been auto‑declined by Jira automation and remained closed without a reopening action recorded. Separately, a requester’s temporary‑admin request was closed by IT because the Minerva access‑management policy disallowed granting temporary administrative rights; the requester was instructed to recreate the request and specify the correct Workday cost‑centre manager so an approver could be identified. A case where a designated approver could not act from the Service Portal UI was investigated; support verified the user’s Service Portal access but no further technical cause was documented. Additional cost‑center instances (for example, CC21229) were reported as routed to incorrect approvers; in at least one instance recommendations were documented in the ticket but not applied. Impacted flows included access requests and downstream purchase‑order/requisition routing through the Service Center.

Issues were resolved by addressing three access-control areas: service/application principal privileges, Azure AD group ownership and role mappings, and individual user table permissions. For application/service principals: the applications were granted the missing Dataverse privileges (including prvRead and other entity privileges), their security roles were updated to include explicit read/create and related-metadata access, column-level security and secured field settings were inspected and removed where they blocked the service accounts, and environment-level access for application users was confirmed; after these changes API calls and Power Automate flows returned relationship data and succeeded. For Azure AD security groups and ownership: designated owners were added so groups could be managed via the CPC_AddUser2Group tool, group-to-role mappings were standardized across environments (admin groups received the app plus Dataverse edit rights, user groups received front-end app access without direct Dataverse edit rights, and the readonly group was renamed and given read-only Dataverse access), and separate environment-scoped group memberships (DEV/PROD) were enabled where required. For individual user access issues: specific user permissions were updated when group-level mapping was insufficient — for example, an account on crfc0_StudentExamDates was changed from read-only to write access to restore edit capability via Power Apps/Flows. These combined changes restored expected API/flow behavior and user editing capabilities without broad privilege escalation.

A Defender for Cloud 'blob-hunting' alert was investigated by enumerating containers (PowerShell was used to list public containers) and inspecting the flagged container. The investigation confirmed the flagged 'public' container contained GUID-named generated image files from a deprecated feature and was not indexable. As part of the account hardening, monitoring and detection were centralised (Log Analytics and Microsoft Sentinel integration) and Azure Defender for Cloud was enabled for threat detection. Public blob/container access was disabled and HTTPS-only enforcement was applied. Network access restrictions (IP whitelisting) were implemented and long-term access keys were rotated and managed to minimise shared key usage. Microsoft-managed encryption keys and key-rotation practices remained in place. The incident also exposed an IAM gap during remediation, so ownership/permission paths were clarified to allow required security changes.

Investigations started with Azure AD sign‑in logs and reproducing failures across networks. Two network‑level causes were identified and resolved: (1) Conditional Access network/location blocklist rules had been blocking mobile‑operator IP ranges (including IPv6/CIDR) and were adjusted so legitimate mobile data traffic was no longer excluded; (2) a perimeter firewall/InfoSec malicious‑IP blocklist had been blocking traffic from a campus WLAN and was removed/cleansed (when the perimeter blocked traffic, affected attempts sometimes produced no Azure AD sign‑in record). A separate Conditional Access cause was identified where third‑party apps (OneCal) or client devices were denied access after a successful sign‑in with Azure AD error 53003 (“You don't have access”); these incidents traced to tenant Conditional Access/app‑consent and device‑registration or device‑compliance requirements and were resolved by changing the tenant Conditional Access/app‑consent or device registration allowances so the authorized app or compliant device could access the resource. After addressing the relevant Conditional Access/policy definitions and firewall blocklist entries, Teams, Outlook and third‑party calendar syncs over the affected networks and devices were restored.

Incidents were resolved by reconciling provisioned identities and system constraints across Learn365/LMS, Azure AD/Entra, Workday-synchronized attributes, Microsoft Teams, Exchange/meeting systems, and the document-generator, and by remediating specific misconfigurations and stale accounts. Specific remediations included: narrowing tenant and Learn365 group-based enrollment targets so assignments applied only to intended AD groups; removing an erroneously assigned system-wide role (CPG_Kommunikationsteam_Standort) from affected student profiles, which restored normal assessment access and removed preview-only behavior; provisioning missing Workday-synchronized manager attributes or adjusting course/group mappings for courses that required the manager attribute, which removed AccessDenied.aspx errors; updating the document generator validation so certificates of study were not issued or downloadable for students with status 'Unter Vorbehalt' (those without active student status); relocating a service account out of an AD group that Learn365 rejected into an alternate AD group accepted by Learn365 and updating mappings; removing legacy myLIBF restrictions that prevented examiner/tutor account switching so selected staff could toggle those accounts; and removing users who were present in a Microsoft Teams Course Feed or distribution list but were not intended members. Stale or suspicious accounts were escalated to specialist teams where appropriate; one ex-matriculated account was deactivated and flagged not to be reactivated. A calendar/meeting-system incident was escalated to security and meeting-systems specialists: termination/disable dates were confirmed, audit logs showed no logins or activity after deactivation, and the behavior was attributed to a known meeting-systems glitch that could cause meeting updates or sender/recipient displays to appear tied to disabled iu.org accounts. For the Academic Lecturer Team, options were reviewed and it was confirmed that Microsoft does not provide a per-Team setting to block team members from creating meetings or inviting external guests; mitigations focused on membership reviews, tenant-level guest/external access controls, and governance changes to reduce risk. Post-change checks confirmed course enrollments, course visibility, assessment behavior, service-account group membership, myLIBF account-switching, Teams Course Feed and distribution-list membership, document-generator behavior, and removal or deactivation of stale/suspicious accounts behaved as intended.

A restrictive Teams Messaging Policy was applied to the user account to disable the chat function (implemented at 15:00) for the disciplinary period. After the two‑week suspension period concluded, the global messaging policy was reassigned to the user to restore chat functionality (re‑enabled at 15:00 two weeks later).

Support retrieved the stored SIM authentication credentials from records and provided the user with the PIN/PUK (and associated SIM codes) for the company phone number.

Investigations identified three root causes for the access/permission symptoms and distinct remediations. First, expired or invalid Okta sessions/authentication tokens caused missing search results, broken Salesforce-to-EPOS links, absent navigation tabs, and loss of edit capability in browser-embedded apps (notably Microsoft Teams and Excel Online). Restoring a valid Okta session consistently restored functionality: in many cases a page reload or signing out and back in refreshed tokens; in some browser scenarios (bookmarked/long-lived Firefox tabs or after tab-switching) the in-page embedded sessions required a full tab close-and-reopen to recover. Clearing browser cache was recommended in one incident but was not confirmed as a definitive fix. Second, separate incidents of access-control failures were traced to malfunctioning Gateway Authorizers; applying a hotfix to the Gateway Authorizers restored authorization behavior and subsequent repository/configuration corrections were recorded to prevent recurrence. Third, some HTTP 403/access-denied search failures were caused by user identity/account misconfigurations — notably outdated email addresses and incorrect approver-role assignments on the user account; correcting the account email and adjusting the approver assignment resolved those access/search failures. Support validated that affected users did not have EPOS permission misconfigurations by comparing their profiles with colleagues before applying identity/role fixes.

An administrator located the two requested Dresden printers and granted the user the required print permissions. The user was informed that permission changes can take time to appear and that off‑campus access requires connecting via VPN. Admin requested exact printer names or a contact who already had access to replicate permissions for any additional missing printers.

The stolen device was reported and a deactivation/lock request was submitted to device management while Cyber Security Services were notified. The user changed their Okta password. A replacement notebook was issued; the initial authentication failure on the new device was transient and later cleared, and the replacement was successfully provisioned. The incident was closed after the lock/password actions and successful replacement provisioning.

Support identified the requesting processes from user screenshots and Activity Monitor as macOS update helper processes — commonly Microsoft Defender's 'install_helper' — that were completing component updates. When the helper was confirmed legitimate, granting the requested access allowed the Defender update to finish and the prompt to stop. In a related incident where an administrative prompt repeatedly appeared after the user ran 'su', the prompt was resolved after the Mac was restarted so pending package installations could be applied; the restart removed the repeated admin popups. Identification via Activity Monitor/screenshots and either granting the helper's access or rebooting to complete pending installs were the observed resolutions.

Support clarified that the iOS/iPadOS prompt was the operating system warning generated when an Exchange ActiveSync account with server‑side device‑level controls was added; it did not indicate automatic MDM enrollment. During investigation no Jamf policies or MDM profiles were being installed by the account setup, and the warning was reproducible only on iOS/iPadOS Apple Mail. The explanation to users and documentation of the behaviour resolved the privacy concern; users who preferred to avoid the prompt were routed to the Outlook mobile app or webmail as alternatives.

Team membership and classification attributes were updated in Azure AD/Teams using administrative automation (PowerShell/Graph where appropriate). The requested classification values were applied to the listed groups (e.g., switching from 'Unmanaged / Students only' to 'Confidential / Employees only' or to 'Trusted / Employees and trusted guests') and the changes propagated to Teams and the Microsoft 365 group objects. The classification updates were performed via scripted admin workflows to ensure consistency and traceability.

The GPO Hardened UNC Paths settings were edited to add or update entries that contained SYSVOL, NETLOGON and relevant UNC patterns and to set RequireIntegrity and RequireMutualAuthentication on those entries. The hardened UNC path configuration change addressed the Ping Castle finding referenced to MS15‑011/MS15‑014, and the updated policy was applied to domain controllers to enforce integrity and mutual authentication for SYSVOL/NETLOGON accesses.

Investigations used a combination of identity verification, log review, and account remediation. For third‑party SaaS notifications support verified the sender domain and that team members could access the shared account from known devices; reporters were advised to avoid links in the notification and to sign in at the official vendor page, and passwords were changed when sign‑ins could not be accounted for. For an identity provider (Okta) sign‑in where logs were not available, the administrator initiated a forced password reset; the user completed the reset and successfully signed in. For Microsoft 365 file‑access concerns investigators asked where the entry was observed (SharePoint in browser, OneDrive, Excel), reviewed Microsoft 365 file access logs and the file’s version/history, and looked for automated integrations or background services that generate activity; in the reported case no access matched the 03:27 AM timestamp and all observed accesses were legitimate. The combination of domain verification, direct sign‑in confirmation, log and version/history review, checking for integrations, and using account resets when events could not be verified resolved the reported incidents.

Technicians reviewed installed configuration profiles and MDM controls on affected Macs and ran a short support session with the user where applicable. The Mac Team confirmed the observed behaviors were caused by institutional device‑management policies that could not be changed locally. Specifically, a lock timeout enforced by IU Admin/IT Security prevented changing screensaver or lock‑screen settings (devices locked on the enforced interval, commonly 10 minutes), periodic Touch ID prompts were required by a security policy and still required the account password, Time Machine had been intentionally disabled by a configuration profile on managed Macs, and the default‑browser setting was managed by a browser/MDM policy (Chrome displayed “managed by your organization”). Local admin access did not remove these restrictions; users were informed that the behaviors were due to device management/profile policies and could not be changed on the device.

Support generated and delivered the user's 1Password recovery key via a one-time secure link and coordinated handoff through a colleague. After the recovery key was provided to the user and used, the user regained access to their 1Password account and no further issues were reported.

Support resolved these issues by ensuring affected accounts were members of the appropriate security groups and by applying the required role assignments. In one incident, support added the user to the existing IUG-LeadershipTeam-Member security group, which granted the requested Microsoft 365/Teams 'My Team' admin membership. In a separate incident, the request was escalated to the specialist team; they created a new security group for the PWA admin accounts, added the specified accounts as members, and adjusted permissions/roles per the provided role attachment so the accounts could perform password resets, manage MFA, and operate Teams groups.

Access was confirmed to be blocked by corporate policy for company-managed devices. The user was informed that iCloud Drive and Apple Passwords were not permitted on corporate systems. Corporate alternatives were recommended (OneDrive for file sync and 1Password for password management). No changes were made to the Mac and the ticket was closed after notifying the user.

Ownership and access problems for collaborative resources were handled depending on the resource type. For Miro boards, support changed board owners when requested, verified licensing, and corrected board-level sharing and team access when sharing settings prevented visibility; after owners or support updated sharing, requesters were able to access the boards. For Confluence spaces, support completed recorded space ownership changes so spaces had current owners. For enterprise calendars, support did not have permission to modify another user’s calendar sharing; support informed requesters that calendar sharing and access revocation were controlled by the calendar owner and must be removed by that owner, and no calendar-side changes were performed by support. Requesters were notified after changes or guidance were provided.

The user’s Freshdesk role was narrowed to remove global/all‑groups visibility and limit access to only the explicitly requested HR groups. Access to Freshdesk and Freshdesk Analytics was granted only for the HR People Admin&Service, HR Print, HR Queue Team, HR Documents, HR Payroll, HR Corona Team, HR International Payroll and HR Jobrad groups. Permission changes were verified and the user’s analytics and group views were confirmed to be limited to those groups.

Datadog role permissions were adjusted to restore Integrations/Webhooks configuration rights after a Datadog role change removed required privileges. The affected role was updated so the user regained configure/manage access for integrations and was able to add webhooks to send alerts to the Teams channel. The user verified creation and editing of webhooks succeeded after the role change.

High‑risk third‑party AI meeting notetaker applications were identified and blocked across identity and meeting controls. Administrators disabled known notetaker enterprise applications/service principals in Azure AD Enterprise Applications and removed their ability to sign in or obtain consent. Where service principals were absent, Conditional Access app blacklists were updated and applied to affected user groups to block specific OAuth apps (for example, Otter.ai and Fireflies.ai). Cross‑tenant/external identity and enterprise‑app consent controls were tightened to prevent new untrusted bots from authenticating.

In incidents where vendors retained access via external OAuth providers, remediation included removing the OAuth application from users’ external accounts (for example removing the otter.ai app from Google) and deleting vendor‑side workspaces or duplicate accounts that had been created using the organization’s domain, which stopped continued mailbox posting and message sending. Calendar integrations and OAuth scopes were audited and revoked where calendar, offline_access, or persistent sign‑in permissions had been granted to notetaker services. Meeting join/authentication policies (lobby, guest restrictions, and requiring authenticated users) were enforced to reduce unauthorized joins.

Platform and group‑level controls and content filters were updated across Teams, Zoom and Google Meet (for example adding known notetaker domains to student blocklists). Conditional Access policies were used where appropriate to block app sign‑ins, and rollback procedures were maintained to address any operational impact.

Support determined that personal/private (unmanaged) devices were not permitted to access the organization's internal network or services. Both local network/printer access and VPN connections from personal devices (including macOS and iOS/iPadOS devices) were blocked per the organization’s device‑management and remote‑access policies. Requesters were informed of the device‑management policy, asked whether they had an organization‑issued/managed device, and advised to use an issued/managed device or follow the organization's approved remote‑access procedures. The ticket was closed after communicating the policy decision.

Support provided a browser‑based workaround and the issue was resolved when the user signed in using the browser's private/incognito mode; services worked successfully in that session. The temporary workaround allowed access to Teams and Outlook while the underlying device state remained unchanged.

The monitoring client Securus XT had been added to the e‑test whitelist following the E‑test installation manual (whitelist instructions referenced on page 18), which stopped it being detected as 'Invalid Access' and prevented the logout/interrupt events. Several affected sessions were also mitigated by using the proctoring software's suspend/resume capability during exams, and by running paper‑based exams when whitelisting could not be applied immediately. A separate set of incidents involved employer‑managed devices where vendor proctoring applets (for example ProctorU's LogMeIn Rescue) or webcam access were blocked by corporate firewalls or device‑management (Intune/company portal); those cases required coordination with the device owner/IT to permit the support applet or webcam, or the candidate to use a personal device or reschedule, because the restrictions originated from the corporate management of the endpoint. It was noted that some monitoring agents could not be uninstalled and that killing their processes could itself trigger logout events, so whitelisting at the e‑test level resolved detection errors where it could be applied.

The team replaced Bitly with short.io as the link‑shortening and click‑tracking solution. After migrating to short.io and onboarding the new service, the retention and analytics requirements were met and the issue was confirmed resolved.

The device app store remained intentionally disabled by corporate policy. The case was resolved by directing the user to the organisation's Self Service Portal on their smartphone to access and install approved applications; Outlook and Microsoft Teams were available there and the user confirmed the installation pathway worked.

Two consistent handling patterns were used depending on the request. For external collaborators who needed ongoing read visibility into tenant audit logs and tenant configuration, the involved external accounts were granted the Azure AD Global Reader role via Azure AD role management; the Global Reader assignments provided the requested read visibility. No alternate built-in role limited to audit-log-only reads was implemented for those requests. For forensic or troubleshooting requests that targeted specific users and time ranges (for example to investigate CourseFeed/MyCampus enrollment events), Microsoft 365 audit-log exports were produced and delivered for the specified users/timeframes instead of issuing tenant-wide role assignments. For Teams app-installation/usage queries (for example identifying which Microsoft Teams instances a bot/service account was installed on), support ran an app-usage/report in the Teams Admin Center and retrieved aggregated usage counts (the report returned 22 Teams and 85 Users within the last 30 days in the reported case) but could not provide lists of specific Teams or users because the analyst lacked the necessary reporting permissions.

Personal private storage was provided by the standard OneDrive application when users signed in with their IU credentials; support confirmed OneDrive was installed and signed in, and that configuration satisfied the requirement for user-only cloud storage. For sensitive files that needed to be shared only among a specific small group, IT recommended creating a cloud-based private Microsoft Teams team or a dedicated SharePoint document library and restricting permissions to the named individuals; this approach was presented as the preferred alternative to on-premise fileshares, which were being deprecated. Requesters accepted the guidance and reported they found a suitable solution; tickets were closed.

The user opened the Jamf/Jamf Connect menu and used the Connect action to reauthenticate with their Okta credentials. After a successful Jamf Connect login the recurring Jamf prompt stopped and the local laptop password became synced with the Okta password, resolving the authentication errors.

Support delivered the BitLocker recovery key to the user (commonly via a one‑time link) and the user used that key to unlock the PC. When multiple recovery keys failed responders confirmed device identifiers/service tag to locate and provide the correct recovery key. Where users could not type the password at the BitLocker prompt responders identified a keyboard‑layout mismatch at the preboot prompt (for example the prompt defaulting to a US layout while the physical keyboard was German QWERTZ); switching the layout resolved the input problem. After the device was unlocked responders restored account access as appropriate for each case — either resetting the user's Windows sign‑in (issuing a new temporary sign‑in password to the user's private email) or resetting the user's Okta authentication method — and confirmed the user regained access.

A YubiKey purchase was approved and a purchase order (PO-007431) was created; IT ordered the hardware and set the delivery address to the user’s campus location, with the user to receive shipment/tracking information once dispatched. For requests about physical custody or georedundant backups, IT confirmed that standard IT offices did not have safes beyond an existing key cabinet. IT offered that, if requesters procured dedicated safes, IT-Ops would securely store YubiKeys in the IT-Ops office at each site and worked with requesters on site custody logistics and contacts.

The depleted battery in the specified alarm zone sensor was replaced. After the replacement the alarm/alert condition cleared and the ticket was closed.

Investigation found the scanner differences were due to DMZ-to-internal routing restrictions and traceroute/ICMP behaviour rather than any mailserver service failure. Fail2Ban behaviour was corrected by consolidating overrides into /etc/fail2ban/jail.local so custom settings took precedence over the packaged /etc/fail2ban/jail.conf; explicit jails were created for sshd (non-standard port 19222) and Postfix-related checks. DEFAULTs were standardized in this environment to bantime=3600, findtime=600, maxretry=5 and ignoreip was populated with known VPN/scanner and AWS SES addresses to reduce false positives. After reloading Fail2Ban, permitted scanners observed the expected open ports (25/587 and 19222) while networks without DMZ routing remained correctly isolated; Nessus traceroute warnings were documented as a network-level artefact rather than a mailserver fault. In a separate SSH brute-force incident against a Nextcloud VM where password authentication was enabled, the affected account password was reset, the new credentials were stored in 1Password and communicated via Microsoft Teams, and the ticket was closed.

A site‑level customer access setting that had disabled the "External account" customer type was re‑enabled in the Atlassian admin console, and a project administrator was assigned to manage the project's customer list. After the external account type was enabled and the project admin managed the customer list, non‑IU email addresses could be invited/added to the Service Portal and previously added external customers became visible.

The WorkFlex policy text was revised to remove references to the deprecated CPG‑VPN and to explicitly describe the current risk posture for public/untrusted Wi‑Fi. NordLayer was designated as the supported replacement and the Service Portal was updated with a NordLayer application entry (onboarding request) that used the existing cost‑center approval workflow. Onboarding and offboarding processes were documented and integrated with centralized license inventory so licenses could be allocated and reclaimed via the Service Portal. NordLayer licensing and vendor capacity were validated for the expected user counts and communications were issued to staff explaining the change and how to request access.

The deleted Teams group was restored and the owner was informed. An audit-log investigation in Microsoft Entra and Teams audit logs identified the deletion as having been performed by an internal IT action. The restoration and investigation resolved the immediate access loss and provided attribution for the deletion; the owner was notified of the outcome and that IT had performed the removal during an internal operation.

A meeting was organized to review tool options and next steps; the Jira Service Management owner (Matthias Wiatrok) was included in the discussion. Proposed approaches considered during the meeting were using Jira Service Management, using a simple Jira board (noting the licensing impact for ~30 site managers), or developing a Power App interface. Further work was deferred to the scheduled follow-up meeting for decision and implementation planning.

Stakeholders established a consolidated roles-and-rights concept for Workday HCM ingestion and the enterprise identity estate and produced deliverables to close the gaps discovered in scope. The artifact enumerated approved HCM fields for API extraction and documented PII tagging and retention categories for DWH ingestion and downstream PowerBI usage. A role-based access model enforced least-privilege view-level access for functional teams while preserving full visibility for DWH administrators. For the broader identity estate, the concept defined consolidated access rules across Windows 11 clients and servers (including Tier0), student/employee/contingent-worker accounts, and privilege-group mappings that identified which groups could view MA-account and client data. Audit sources and monitoring pipelines were enumerated (Workday API logs, DWH ingestion and access logs, on‑prem AD and EntraID/Azure AD logs, Okta authentication logs, and Microsoft Sentinel alerts), and access-event quality gates were specified (permitted vs denied, logged-only, logged-plus-actively-monitored). Data-protection controls were captured (encryption in transit and at rest, PII tagging and retention), and group-management templates and role-definition documentation were produced. In response to discovered unmanaged service/ISU accounts, the deliverable was extended to include an ISU inventory and ownership register, classification of ISUs by purpose and business owner, identification of inactive ISUs, and a recorded remediation plan that covered password-rotation integration with the WCC service (an initial WCC password refresh occurred in August 2025) and lifecycle steps for owner changes and deprovisioning. The work also documented gaps where HR review did not consistently cover finance/IT or vendor-related ISUs and recorded actions to assign accountable owners and integrate ISU governance into the consolidated roles-and-rights model; those remediation actions were recorded but not fully implemented at the time of reporting.

The group's mail settings were modified to block incoming messages: send/receive permissions were adjusted so the dynamic/security group no longer accepted email. The configuration change removed the unintended mail delivery capability and the group's status was updated to reflect the new incoming‑message restrictions.

Sign‑in enforcement was implemented by distributing a Docker Desktop build configured with registry.json enforcement through the internal package deployment pipeline and Company Portal, and by scoping that deployment to the engineering cost‑center AD/group. The scoped package required Docker sign‑in for users who received the deployment; WSL integration remained unchanged. Education and lecturer accounts were excluded by omitting them from the targeted deployment group so they could continue to use Docker Desktop without registration.

Resolutions followed one of two paths depending on availability of packaged software in the corporate self‑service tooling. When the Company Portal offered the required JDK package, the user accepted the packaged version and no local administrator elevation or device changes were performed. In cases where no suitable package existed, the user submitted an access request through the SelfService App and local administrator rights were granted; the user then installed the required software and confirmed the issue was resolved. Systems involved in these tickets were the end‑user laptop and the Company Portal / SelfService self‑service tooling.

Investigation found the portal's Jira Forms 'Organizations' field allowed requesters to share their own requests with the IU Group, which triggered group notification rules. Engineers removed the IU Group association from the affected requests and adjusted the portal's organization visibility/notification configuration so that requesters could not inadvertently notify the whole IU Group. After removing the organization association and tightening the organization-sharing settings, group-wide email notifications ceased.